home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / doc / www_talk.arc / 000243_connolly@pixel.convex.com _Fri Oct 16 20:29:37 1992.msg < prev    next >
Internet Message Format  |  1992-11-30  |  5KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA14807; Fri, 16 Oct 92 20:29:37 GMT+0100
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA23927; Fri, 16 Oct 92 20:30:12 +0100
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA06628; Fri, 16 Oct 92 14:29:27 -0500
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA21965; Fri, 16 Oct 92 14:29:24 -0500
  10. Message-Id: <9210161929.AA21965@pixel.convex.com>
  11. To: www-talk@nxoc01.cern.ch
  12. Cc: Jim Davis <davis@dri.cornell.edu>
  13. Subject: Re: non-text documents
  14. In-Reply-To: Your message of "Fri, 16 Oct 92 12:11:46 EDT."
  15.              <199210161611.AA06348@willow.tc.cornell.edu> 
  16. Mime-Version: 1.0
  17. Content-Type: multipart/mixed; boundary="8<"
  18. Date: Fri, 16 Oct 92 14:29:23 CDT
  19. From: Dan Connolly <connolly@pixel.convex.com>
  20.  
  21.  
  22. --8<
  23.  
  24. >Can you tell us when WWW and Viola will support non-text
  25. >documents?  I would very much like to be able to return
  26. >pictures including Postscript.  I know this has been discussed
  27. >in the past.
  28.  
  29. That discussion in the past never really went anywhere. I'm going
  30. over my suggestions, and I'd like to summarize them here and solicit
  31. support.
  32.  
  33. If we use the semantics of the MIME body part to define a WWW
  34. document, many of these issues have straightforward solutions, and
  35. there is hope of interoperating with other MIME compliant systems.
  36. For example, I also hope WAIS and gopher will use the MIME typing
  37. system.
  38.  
  39. This means every document has an associated Content-Type and
  40. Content-Transfer-Encoding. The MIME RFC defines content types for
  41. text, image, audio, video, and application data, and two encapsulation
  42. types message and multipart. Text, GIF, postscript, and several other
  43. commonly used data formats are mentioned in the standard. And there is
  44. a well-defined method for adding formats to MIME.
  45.  
  46. It does _not_ mean that all 8-bit data has to be base64 encoded. 8bit
  47. is a perfectly valid Content-Transfer-Encoding, if you're using FTP or
  48. WAIS or some other 8-bit-clean transport mechanism. But if you're
  49. using email or HTTP, base64 solves the issue quite neatly.
  50.  
  51. Nor does it mean that all documents look like RFC-822 messages.
  52. Messages is one _type_ of MIME body part. The text/plain type covers
  53. plain text documents. Image/gif is good for lots of pictures.
  54. Application/postscript covers printer-ready stuff. Unknown data can be
  55. tagged application/octet-stream. And you can use types starting with
  56. "x-" for experimental private types.
  57.  
  58.  
  59. WWW should use typed links, either implicitly or explicitly. For example,
  60. client software can infer the type of a link to a USENET news article
  61. to be message/rfc-822. But it should not assume that a link to a file
  62. on an FTP server is text! That link should include the type of the
  63. data so that the client software can process it intelligently. There's
  64. already quite a bit of this going on in the WWW browser code. The MIME
  65. semantics are just a way to formalize it with the possibility of
  66. interoperating with other systems.
  67.  
  68. For example, if an anchor that points to a postscript format document
  69. should look like:
  70.  
  71. <A href="http://info.cern.ch/hypertext/foo.ps"
  72. type="application/postscript"> here is a postscript file.</A>
  73.  
  74. I wrote a proposal to recast the whole syntax of URLs so that the
  75. above sample would look more like:
  76.  
  77. <A><HTTP host="info.cern.ch" path="hypertext/foo.ps"
  78.          type="application" subtype="postscript">
  79. here is a postscript file.</A>
  80.  
  81. The ideas is that we've already got some sort of SGML parser: why not
  82. let it do the work of parsing the URL too? We could use SGML features
  83. for certain semantics; we could use the SGML numeric character entity
  84. reference ({) in stead of the %FF quoting scheme, and we could
  85. use attribute default values to infer type, subtype, and other
  86. attributes.
  87.  
  88. I also think we should have optional identity information in the
  89. links. This allows clients to determine whether two links point to the
  90. same information. For example, someone might extend some FTP an WAIS
  91. servers to return the MD5 signature of documents. Then a client could
  92. conclude (with some very high probability) that
  93.  
  94. <ftp host="cs.utexas.edu" path="contrib" name="x.tar.Z" md5="abcdef">
  95.  
  96. and
  97.  
  98. <wais host="quake.think.com" database="software" path="x-2.1.tar.Z"
  99.   md5="abcdef">
  100.  
  101. refer to the same release of the package.
  102.  
  103. Thoughts?
  104.  
  105. Dan
  106.  
  107. p.s. I've attached the MIME RFC below. If you've got a MIME mail UA,
  108. it should be able to bring up the text. If not, there's enough info
  109. for you to ftp the thing manually.
  110.  
  111. --8<
  112. Content-Description: RFC1341 MIME  (Multipurpose Internet Mail Extensions)
  113. Content-Type: message/external-body;
  114.     access-type=anon-ftp;
  115.     site="thumper.bellcore.com";
  116.     dir="pub/nsb";
  117.     name="BodyFormats.txt";
  118.     size=214081
  119.  
  120. Content-Type: text/plain
  121.  
  122.  
  123. --8<--